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Abstract 

Decision  help  and  decision  analysis  arc  tools  that  will  be  of  importance  in 
decision  support  systems.  They  arc  likely  to  exist  both  in  real  operational 
systems  and  in  simulation  based  systems  used  for  training.  In  command  and 
control  an  example  of  a  decision  task  is  to  command  units  in  a  geographical 
environment.  We  have  taken  a  closer  look  at  this  type  of  decision  task,  using 
a  simulated  microworld  as  a  research  tool.  In  particular  we  arc  interested  in 
the  case  when  the  decision  maker  already  has  selected  a  course  of  action, 
but  wants  to  have  critique  and  suggestions  of  improvements.  To  analyze  a 
decision  where  the  “main  direction”  is  already  known  in  this  way  we  denote 
decision  analysis,  as  opposed  to  decision  help. 

An  algorithm  for  decision  analysis  in  maps  has  been  developed.  This 
algorithm  is  based  on  rules.  An  implementation  in  Java  with  classes  suited 
for  reuse  has  been  developed.  The  implementation  has  been  tested  in  a  mi¬ 
croworld  system,  C3FIRE,  suited  for  practice  in  forest  tire  fighting. 

1  Introduction 

Decision  making  in  emergency-  and  military  organizations  is  classified  as  dis¬ 
tributed  decision  making[ 9]  which  means  that  the  decision  making  is  distributed 
among  the  actors  in  the  organization.  These  ideas  influence  the  ongoing  research 
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in  command  and  control[l,  11,  13,  16,  18,  20],  and  also  seem  to  be  the  goal  for 
products  currently  under  development  19]. 

Making  a  decision  can  be  seen  as  the  task  of  finding  a  certain  process  that  can 
be  used  to  control  some  other  process/processes  in  the  system.  The  goal  of  the 
decision  maker  is  to  analyze  the  state  of  the  system  and  try  to  see  what  existing 
processes  he  or  she  can  use  and  control  to  fulfill  his  goal.  In  [6,  7,  10]  decision 
making  in  a  complex  system  is  characterized  by  the  following  properties: 

•  A  series  of  decisions  are  necessary. 

•  The  decisions  are  dependent  on  each  other. 

•  The  state  of  the  decision  problem  changes,  both  autonomously  and  as  a 
consequence  of  the  decision  makers  actions. 

•  The  decisions  have  to  be  made  in  real  time. 

These  four  properties  form  a  subset  within  the  distributed  decision  making,  clas¬ 
sified  as  dynamic  decision  making. 

2  Decision  making 

2.1  Decision  theory 

There  exist  many  theories  for  decision  making.  In  classic  decision  making  the 
decision  tree  is  often  used.  This  gives  a  programmed  decision  rule,  that  can  be 
obtained  from  knowledge  of  plausible  situations  and  their  right  responses,  or  by 
machine  learning  from  a  repository  of  previous  cases.  In  this  paper  another  com¬ 
mon  theory  for  decision  making  using  utility  matrices  and  probability  estimates  is 
described[5,  14,  17].  The  utility  matrix  partly  solves  the  problem  of  the  decision 
tree. 

2.1.1  Introduction 

We  apply  a  Bayesian  approach,  although  it  is  not  undisputed.  It  is  however 
supported  by  numerous  of  successful  applications  and  experiments [2].  Roughly 
speaking,  the  Bayesians,  or  subjectivists,  wish  to  introduce  intuitive  judgments 
and  feelings  directly  into  the  formal  analysis  of  a  decision  problem.  The  non- 
Bayesians,  or  objectivists[  17],  feel  that  these  subjective  aspects  are  best  left  out  of 
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the  formal  analysis  and  should  be  used  only,  if  at  all,  to  bridge  the  gap  between 
the  real  world  and  the  objective  results  one  obtains  using  a  formal  model. 

The  analysis  of  a  decision  problem  under  uncertainty  requires  the  following 
steps[17]: 

1.  list  the  viable  options  available  to  you  for  gathering  information,  for  exper¬ 
imentation,  and  for  action, 

2.  list  the  events  that  may  possibly  occur, 

3.  arrange  in  chronological  order  the  information  you  may  acquire  and  the 
choices  you  may  make  as  time  goes  on, 

4.  decide  how  well  you  like  the  consequences  that  result  from  the  various 
courses  of  action  open  to  you, 

5.  judge  what  the  chances  are  that  any  particular  uncertain  event  will  occur. 

After  taking  these  steps,  meaning  that  your  problem  is  systematically  described 
and  your  preferences  and  judgments  are  recorded,  we  can  start  applying  a  strategy 
aiming  towards  a  solution. 

2.1.2  Theory 

Consider  every  possible  world,  cu*,  and  let  every  such  world  occur  with  possibility 
Pi.  We  have  a  number  of  possible  actions,  Hj,  that  we  can  perform.  Further,  let 
Mt  j  be  the  utility  of  performing  action  Hj  in  the  world  jjt.  If  we  perform  action 
Hj  we  get  the  following  expected  utility  for  action  Hj\ 

n 

E(Mj )  =  5>MW 
2—1 

We  want  to  choose  an  action,  Hj,  so  that  we  achieve  as  big  expected  utility  as 
possible.  Therefore  we  choose  Hj  so  as  to  maximize  the  sum  above. 

In  many  cases  the  possible  worlds  and  actions  are  described  as  continuous.  In 
such  cases  the  mathematics  gets  more  complicated.  The  principles  are  the  same, 
though. 
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2.1.3  An  example 

A  military  base  observes  radar  echos  to  assess  a  possible  missile  threat.  Hence 
there  are  two  possible  worlds,  u>i  and  tu2: 

•  u>i  means  that  a  real  threat  exists, 

•  cu2  means  that  there  is  no  threat. 

We  can  perform  two  possible  actions,  H\  and  H2,  meaning  the  following: 

•  H\  means  that  we  do  not  do  anything  at  all, 

•  H2  means  that  we  fire. 

In  this  way  we  achieve  a  2  x  2-matrix  with  four  different  M -values,  where  for 
example  M22  defines  the  utility  of  shooting  when  no  real  threat  exists  and  M12 
defines  the  utility  of  shooting  when  there  is  a  real  threat.  If  the  decision  support 
system  is  implemented  in  a  clever  way  M2  2  should  then  contain  a  low  value  (low 
utility)  and  Mij2  a  high  value  (large  utility). 

The  utility  of  firing  if  the  observed  echo  comes  from  a  real  threat  is  of  course 
big.  If  you  are  really  being  attacked  the  radar  plots  are  likely  to  advocate  world 
with  larger  and  larger  possibility  (i.e.,  p\  increases  and  p2  decreases).  After  a 
while  the  expected  utility  for  action  H2  will  win  and  we  fire. 

For  the  interested  reader  it  can  be  interesting  to  know  that  this  example  has  a 
connection  to  reality.  According  to  [14]  a  NATO-base  on  Greenland  had  problems 
with  birds  in  the  1960:s.  These  birds  flew  higher  than  thought  possible  when 
developing  the  system.  This  resulted  in  increasing  possibility  for  a  real  threat  and 
one  came  very  close  to  firing  (exactly  how  close  is  secret). 

2.2  Decision  help 

We  define  decision  help  as  a  tool  that  helps  the  commander  look  at  the  whole  pic¬ 
ture,  in  order  to  suggest  a  course  of  action.  We  think  of  decision  help  implemented 
as  a  tool  connected  to  a  computer  system  where  one  needs  to  make  decisions. 

2.3  Decision  analysis 

We  define  decision  analysis  as  a  tool  that  gives  the  commander  feedback  and 
suggestions  of  improvements  regarding  a  specific  course  of  action.  We  think  of 
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decision  analysis  implemented  as  a  tool  connected  to  a  computer  system  where 
one  needs  to  analyze  decisions. 

Suppose  that  a  decision  maker  has  understood  the  situation  and  knows  what  to 
do  (i.e.,  situation  awareness).  The  decision  maker  is  now  interested  in  analyzing 
his  decision  to  get  feedback  regarding  risks  he  ought  to  pay  attention  to  and  sug¬ 
gestions  for  improvements  regarding  his  decision.  He  is  not  interested  in  finding 
out  what  to  do,  when  looking  at  the  whole  picture,  since  he  has  already  selected  a 
course  of  action.  He  is  interested  in  help  with  the  decision  he  has  actually  decided 
to  perform. 

2.4  Decision  help  versus  decision  analysis 

In  research  performed  at  the  Swedish  National  Defence  College[3,  4,  16]  the  issue 
of  decision  help  versus  decision  analysis  has  been  analyzed.  Decision  help  and 
decision  analysis  are  both  tools  that  should  be  included  in  a  computer  support  for  a 
commanders  decision  making.  It  has,  however,  been  pointed  out  that  the  decision 
help  must  not  be  given  a  status  of  great  importance.  It  is  important  that  a  decision 
maker  takes  part  in  the  decision  process  and  takes  his  own  decisions,  regardless 
what  a  computer  tells  him.  Moreover,  humans  are  good  at  finding  general  patterns, 
but  are  not  good  at  analyzing  details.  With  this  in  mind  the  decision  analysis  has 
been  considered  as  a  more  important  tool  than  the  decision  help. 

3  A  way  to  perform  decision  analysis 
3.1  Limitations 

Decision  analysis  can  be  performed  in  many  ways.  In  this  work  a  limitation 
has  been  that  the  analysis  is  supposed  to  be  performed  on  decisions  concerning 
“moves”  in  a  geographical  area  (i.e.,  a  map).  The  specifications  on  this  geograph¬ 
ical  area  are  best  kept  as  general  as  possible. 

The  geographical  area  can  be  represented  as  a  large  matrix  where  each  matrix 
element  corresponds  to  a  particular  spot  on  the  geographical  area.  Each  element 
then  needs  to  keep  track  of  the  following  information: 

1.  a  set  of  environmental  parameters  characterizing  this  spot, 

2.  the  prevailing  state  for  this  spot. 

For  a  decision  support  system,  where  the  domain  is  forest  fire  fighting,  the  above 
mentioned  information  could  be  the  following: 
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1.  normal  tree,  young  pine  tree  (fast  burning),  birch  tree  (slow  burning),  and 
houses, 

2.  not  burning,  burning,  put  out,  and  burned  out. 

By  requiring  that  our  map  is  represented  in  this  way  we  can  use  our  system 
for  decision  analysis  in  a  broad  range  of  applications.  By  changing  the  attributes 
of  the  matrix  elements  we  can  define  cities,  mountains  or  an  archipelago.  By 
changing  the  possible  states  we  can  define  all  types  of  possible  scenarios  that  we 
are  interested  in,  for  example  fire  situations,  nuclear  disasters  and  war  scenarios. 

In  a  large  system  we  want  to  have  more  details  and  we  obtain  that  by  increasing 
the  number  of  possible  geography  types  and  the  number  of  possible  states.  We  can 
not  keep  everything  we  make  and  reuse  it,  though.  Every  system  is  designed  for  a 
special  purpose  and  uses  particular  types  of  states  for  this  purpose.  Also  different 
scales  regarding  geography  resolution  is  used. 

Additionally,  a  system  consist  of  moving  units.  In  a  decision  support  system 
designed  for  forest  fire  fighting  you  need  fire  fighting  units  that  can  move  around. 
Since  these  moving  units  do  not  belong  to  a  particular  spot  on  the  map,  it  is  better 
to  keep  track  of  them  separately.  Besides,  such  moving  units  have  their  own  char¬ 
acteristics  and  they  are  therefore  best  seen  as  a  set  of  “objects”  (easily  modeled  in 
an  object  oriented  environment).  One  way  to  describe  the  characteristics  of  a  par¬ 
ticular  moving  unit  is  to  let  it  belong  to  one  particular  state,  out  of  a  finite  number 
of  different  states.  We  believe  that  this  way  of  describing  the  characteristics  of  a 
moving  unit  is  sufficient  for  most  of  the  systems  one  wants  to  develop. 

A  way  of  referring  to  these  units  must  be  possible.  Therefore  the  units,  as  well 
as  the  geography,  must  be  defined  in  a  general  way. 

3.2  Solution 

The  idea  we  have  developed  is  to  design  a  system  based  on  rules  that  performs 
the  decision  analysis  on  a  given  move  on  the  map.  As  input  data  the  analysis 
application  requires  a  map  (represented  as  a  matrix  on  the  form  discussed  above) 
and  the  coordinates  for  the  move  that  is  going  to  be  analyzed.  The  map  is  matched 
towards  a  set  of  rules  (actually  a  set  of  sets  of  rules,  see  section  3.3.3).  As  output 
the  system  delivers  the  results  of  the  analysis.  The  result  consists  of  a  number 
of  text  strings  with  suggestions  of  improvements,  criticism  etc.  regarding  the 
proposed  move.  Exactly  what  type  of  answers  you  will  get  depends  on  how  you 
define  your  rules. 
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To  keep  the  system  as  general  as  possible,  the  rules  and  the  map  definitions 
are  kept  in  text  files  that  can  be  easily  adjusted.  Besides  that,  the  rules  are  defined 
using  the  terminology  developed  when  constructing  the  map-  and  unit  definitions. 

The  rules  focus  on  small  matrices  around  the  path  that  the  decision  maker 
has  decided  he  wants  to  move  along.  If  a  small  matrix  exists  that  fulfills  the 
requirements  of  a  rule,  this  rule  is  a  matching  one. 

3.3  Rules 

The  amount  of  possible  input  data  for  an  analysis  application  grows  rapidly  when 
the  playing  field  (the  map  matrix)  increases  in  size.  Due  to  all  different  types  of 
vegetation,  states  and  the  fact  that  the  amount  of  matrix  elements  grows  faster 
when  the  matrix  is  big,  the  amount  of  different  possible  inputs  soon  becomes 
impossible  to  handle.  Thus,  we  can  conclude  that  the  trivial  approach,  meaning 
that  we  make  a  rule  for  each  map,  is  out  of  the  question.  Other  techniques  must 
be  considered. 

3.3.1  One  rule 

A  rule  consists  of  a  pattern  and  an  answer.  When  the  pattern  in  a  certain  rule 
matches  the  input  data  the  answer  in  this  particular  rule  applies.  Our  idea  is  to 
look  at  the  start-  and/or  the  stop  coordinates  of  the  move  to  be  analyzed.  The 
pattern  in  a  rule  defines  a  small  matrix  around  either  the  start-  or  the  stop  point 
(or  both),  see  figure  1.  This  small  matrix  contains  information  about  what  states, 
vegetations  and  moving  units  that  are  allowed  for  each  spot  in  the  matrix.  Besides 
this,  the  small  matrix  also  contains  information  on  where  in  the  small  matrix  the 
start-  and/or  stop  point  should  be  located.  This  idea  reduces  the  amount  of  rules 
needed  significantly. 

When  the  matching  is  to  be  made  the  start-  and/or  stop  point  is  used  to  ef¬ 
ficiently  indicate  where  in  the  map  it  shall  search  for  the  small  matrix.  The 
matching  is  performed  by  comparing  the  information  in  the  small  matrix  with 
the  corresponding  information  in  the  map.  As  soon  as  an  item  that  does  not  fit 
is  encountered,  the  matching  stops  with  an  error.  On  the  other  hand,  if  all  items 
in  the  small  matrix  are  walked  through  and  match  the  corresponding  items  in  the 
map  this  rule  is  a  matching  rule. 

The  idea  of  only  looking  at  the  start-  and/or  stop  point  can  clearly  be  discussed. 
However,  in  this  project  we  found  this  idea  to  be  the  best  one  and  wanted  to  test 
the  results  it  gives.  We  do  not  in  any  way  claim  that  this  is  the  only  way  or  the 
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Figure  1:  The  rules  focus  on  small  matrices  around  the  start-  and/or  stop  point  of 
a  given  move.  Information  in  the  big  matrix  must  agree  with  the  information  in 
these  small  matrices  in  order  for  a  rule  to  apply. 


best  way  an  analysis  should  be  committed.  We  do  think  that  it  is  an  interesting 
approach  worth  trying,  though. 

3.3.2  Rotation 

For  now  we  have  not  been  able  to  come  up  with  one  single  reason  to  make  the 
system  different  in  any  of  the  four  cardinal  points.  Therefore  we  suggest  that 
the  system  is  being  implemented  so  that  each  rule  is  applied  in  all  four  different 
directions.  This  is  in  theory  easily  applied  by  rotating  the  small  matrix  90°  three 
times  after  the  first  matching,  applying  new  matches  between  each  rotation. 

It  would  be  easy  to  include  an  option  in  the  rule  that  indicates  however  this 
rule  should  be  rotated  or  not.  As  mentioned  we  have  not  found  a  reason  for  this, 
though. 

3.3.3  Many  rules 

Some  of  the  rules  you  might  think  of  when  writing  your  rule  base  depend  on 
each  other  while  other  rules  do  not  depend  on  each  other.  An  example  of  rules 
depending  on  each  other  in  the  case  of  a  system  developed  for  fire  fighting  is 
when  you  want  to  develop  the  following  idea: 
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If  the  commander  proposes  that  a  fire  unit  shall  leave  a  spot  with  a 
house,  then  give  a  warning  (it  is  more  important  to  protect  houses  than 
to  protect  ordinary  forest).  However,  if  another  fire  unit  is  located  on 
the  same  spot  as  the  one  that  is  proposed  to  leave,  no  warning  should 
be  given  (the  warning  is  then  useless). 

A  nice  way  to  implement  this  when  “thinking  rules”  is  to  use  the  following  two 
rules  where  you  require  that  only  the  first  matching  one  is  taken: 

1.  If  a  fire  unit  is  leaving  a  spot  with  a  house  and  at  least  one  more  fire  unit  is 
present,  do  not  suggest  anything  at  all. 

2.  If  a  fire  unit  is  leaving  a  spot  with  a  house  then  give  a  warning. 

Typically  you  want  to  be  able  to  instruct  the  system  that  a  certain  rule  should  only 
be  used  if  another  rule  has  not  been  giving  a  correct  matching.  However,  there 
are  rules  that  still  should  be  considered  independently  of  the  fact  that  other  rules 
have  already  given  a  correct  matching.  For  example,  look  at  the  following  rule 
and  compare  it  to  the  examples  above: 

Look  at  the  stop  point  of  the  proposed  move.  If  there  is  fire  there,  then 
give  positive  feedback  to  the  commander  saying  “Your  target  position 
is  on  fire.  This  seems  like  a  good  move.”. 

We  consider  this  problem  by  proposing  that  the  rules  are  divided  into  sub¬ 
groups  where  only  one  rule  in  each  subgroup  can  apply.  In  each  such  subgroup 
the  rules  are  listed  in  priority.  When  the  analysis  is  performed  each  group  with 
rules  is  traversed  until  a  matching  rule  is  found  or  the  group  is  empty.  After  that 
the  analysis  moves  on  to  the  next  rule  group. 

3.4  Generality 

An  important  aspect  of  the  idea  discussed  above  is  that  it  will  work  well  for  an¬ 
alyzing  any  type  of  map.  The  concepts  are  general  and  are  not  limited  to  maps 
within  a  specific  system,  but  will  work  with  any  system  where  you  use  a  map  for 
representation  of  a  certain  world  or  situation. 

The  typical  situation  is  that  you  have  a  map  representing  the  world  in  the 
currently  known  way.  It  does  not  matter  if  information  on  the  map  is  incorrect 
because  what  you  want  to  do  is  to  analyze  the  situation  with  a  map  representing 
the  world  in  the  way  you  think  it  looks  like.  If  you  later  on  get  information  about 
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changes  in  the  world  that  the  map  represents  you  analyze  again  given  this  new 
map  data. 

Primarily  we  think  of  a  system  that  already  uses  maps  where  you  can  integrate 
the  ideas  of  decision  analysis  directly.  Such  systems  typically  update  the  informa¬ 
tion  on  the  map  with  respect  to  the  information  that  the  system  receives.  In  such 
systems  the  decision  analysis  can  be  performed  in  an  easy  way  by  just  indicating 
the  position  you  are  aiming  for  to  receive  the  analysis. 

4  Application  on  a  dynamic  problem 

4.1  Microworld  simulations 

Computer  simulations  of  real  world  phenomena  gains  importance  in  all  sciences. 
As  computer  power  increases  the  real  world  simulations  get  more  detailed.  We 
will  study  schematic  simulated  worlds  called  microworlds[ 8].  In  such  micro¬ 
worlds  it  is  possible  to  provide  the  players  with  the  latest  technology  available 
today  as  well  as  the  technology  of  tomorrow. 

Many  examples  of  realistic  microworlds  can  be  seen  in  the  war  games  avail¬ 
able  for  personal  computers  on  the  commercial  market.  The  games  available  today 
are  not  suited  for  research  purposes[15],  mainly  because  you  are  not  allowed  to 
register  information. 

4.2  The  C3FIRE  microworld 

In  our  research  we  have  implemented  a  decision  support  system  in  the  C3FIRE 
microworld[12].  C3FIRE  is  a  command,  control  and  communication  experimen¬ 
tal  simulation  environment.  The  primary  purpose  of  the  system  is  to  allow  re¬ 
searchers  to  experiment  with  different  strategies  for  studies  and  training  of  per¬ 
sonnel.  The  domain,  which  is  forest  fire  fighting,  is  of  subsidiary  interest  and  has 
been  chosen  simply  to  demonstrate  the  principles. 

The  system  generates  a  task  environment  in  which  team  members  cooperate 
to  extinguish  a  forest  fire.  The  simulation  includes  the  forest  fire,  houses,  different 
kinds  of  vegetation,  computer-simulated  agents  such  as  reconnaissance  persons, 
and  fire-fighting  units.  The  participants  in  the  simulation  are  parts  of  a  fire-fighting 
organization  and  take  the  roles  of  staff  members  or  fire-fighting  unit  leaders,  see 
figure  2. 
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Figure  2:  The  C3FIRE  microworld. 


4.3  C3FIRE  integration 

Since  the  C3FIRE  is  implemented  in  Java  it  felt  natural  to  use  Java  for  the  im¬ 
plementation  of  the  decision  analysis.  Java  is  an  object  oriented  programming 
language.  This  suits  us  very  well  since  there  are  many  natural  objects  in  a  mi¬ 
croworld  system  that  are  easy  to  identify. 

The  implementation  has,  however,  been  made  completely  separated  from  the 
C3FIRE.  The  goal  has  been  to  construct  a  system  as  general  as  possible.  Therefore 
we  made  a  system  which  uses  a  world  totally  defined  in  easily  adjustable  text 
files.  Also,  abstraction  and  documentation  of  the  provided  interface  have  been 
important  issues.  The  development  has  been  made  in  three  phases: 

1.  Implementation  of  a  class  representing  the  decision  analysis.  The  goal  has 
been  to  make  a  good  abstraction  so  that  the  system  can  be  easily  integrated 
in  any  system  implemented  in  Java. 

2.  Construction  of  a  tool,  DAT,  that  parses  log-files  from  C3FIRE,  creates  a 
map  given  the  data  from  these  log-files  and,  creates  an  instance  of  the  de¬ 
cision  analysis  class  and  then  uses  this  instance  to  perform  an  analysis  on 
the  generated  map.  This  tool  gave  us  the  opportunity  to  test  our  ideas  in  an 
easy  way. 

3.  Integration  in  C3FIRE,  see  figure  3. 
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Figure  3:  C  ’FIRE  with  new  analysis-capabilities  implemented. 


By  performing  the  work  in  this  way  we  got  feedback  in  phase  three  on  how  well 
the  work  in  phase  one  was  actually  performed.  The  integration  in  C3FIRE  went 
very  smooth  so  the  above  described  way  of  performing  the  work  now  seems  to 
have  been  a  successful  idea. 

5  Conclusions 

We  have  defined  two  very  helpful  tools  that  should  be  available  when  implement¬ 
ing  a  system  for  command  and  control,  decision  help  and  decision  analysis. 

The  decision  help  should  be  implemented  so  that  the  commander  does  not  tend 
to  use  it  too  much.  It  is  important  that  the  commander  takes  part  in  the  decision 
process  to  fully  understand  the  whole  situation  picture  and  its  potentials. 

The  decision  analysis  has  shown  to  be  a  very  useful  tool  and  research  ought 
to  be  continued  in  this  area.  Exactly  how  the  decision  analysis  should  be  im¬ 
plemented  is  still  to  be  explained,  but  it  seems  obvious  that  a  tool  for  decision 
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analysis  imposes  no  drawbacks  on  a  system  for  command  and  control. 

6  Future  work 

The  area  of  decision  analysis  should  be  investigated  further  and  tested  in  other  ap¬ 
plications.  Different  sets  of  rules  should  be  implemented  and  investigated.  Ques¬ 
tions  that  need  to  have  answers  are: 

•  Is  it  possible  to  create  a  generic  algorithm  for  decision  analysis? 

•  Are  you  only  interested  in  critique,  or  is  it  also  interesting  to  get  positive 
feedback?  Should  the  critique  be  given  higher  priority  than  the  positive 
feedback? 

•  Different  users  may  have  different  requirements  regarding  the  given  anal¬ 
ysis.  One  user  might  wants  to  have  positive  feedback  while  another  user 
prefers  not  to  have  it.  One  user  might  wants  to  have  detailed  information 
while  another  user  prefers  to  see  the  whole  picture.  Should  the  system  in¬ 
clude  different  rule -bases  that  the  commander  can  choose  between? 

•  How  many  rules  are  required  when  implementing  a  tool  for  decision  anal¬ 
ysis  in  reality?  Can  we  make  a  system  that  performs  good  enough  using  a 
limited  amount  of  rules? 

•  How  do  you  eliminate  information  overflow  when  many  rules  apply  at  the 
same  time? 

•  Scalability  is  an  important  issue.  How  do  we  implement  applications  so 
that  they  can  take  care  of  maps  covering  the  whole  world  as  well  as  maps 
covering  a  single  neighborhood? 
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